Enhanced header compression profile

ABSTRACT

An apparatus and method, in a data network to compress headers of packets that carry media information having an RTP TS which cannot be linearly extrapolated from the RTP SN.

FIELD OF THE INVENTION

[0001] The invention relates to robust header compression.State-of-the-art robust header compression scheme compress theRTP/UDP/IP headers to typically one byte for audio streams and two bytesfor video streams. This new scheme compresses the RTP/UDP/IP headers ofsome video streams to one byte.

BACKGROUND OF THE INVENTION

[0002] The current problem of header compression is that, for some mediasuch as video, both compressed sequence number (SN) and compressedtimestamp (TS) have to be sent in most, if not all compressed packets.The invention allows one to send only the SN, and derive TS from SN.

SUMMARY OF THE INVENTION

[0003] The new scheme takes advantage of the pattern observed in themedia stream to allow the compressor to get into the highest compressionstate (SO or second order state) more often.

[0004] Other advantages will be readily appreciated, as the inventionbecomes better understood by reference to the following detaileddescription and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005]FIG. 1 shows typical cases of TS as a function of SN for audio;

[0006]FIG. 2 shows typical cases of TS as a function of SN for video;

[0007]FIG. 3A shows SO pattern, TS as a function of SN;

[0008]FIG. 3B shows IP-ID as a function of SN;

[0009]FIG. 3C shows M bit as a function of SN; and

[0010]FIG. 4 is a logic diagram showing the compressor logical states.

DETAILED DESCRIPTION OF THE INVENTION

[0011] Header compression framework:

[0012] This application claims the benefit of U.S. ProvisionalApplication No. 60/236,120, filed Sep. 28, 2000 and U.S. ProvisionalApplication No. 60/239,703 filed Oct. 12, 2000.

[0013] For an overview of the robust compression framework, refer toRobust header compression (ROHC), draft-ietf-rohc-rtp-02, draft internetRequest For Comments (RFC), which is attached as an appendix hereto andincorporated by reference. This will be referred to hereafter as thecurrent scheme or ROHC. The compression can be in three differentstates: initialization, first order, second order. In the initializationstate, the compressor sends full header packets (no compression). Infirst order state, it sends FO packets which contain only encodeddynamically changing fields. A typical FO header size is two bytes ormore. In SO state, it sends only an encoded SN. The SO state is definedrelative to a pattern that a series of header fields follow. There aredifferent modes in which the compression scheme can operate. In reliablemode, the compressor makes sure, through decompressor acknowledgements,that the decompressor is synchronized before going to a highercompression state. In unidirectional or optimistic mode, if thecompressor estimates that under all likelihood the decompressor issynchronized, it then goes to a higher compression state. Optimistic andunidirectional mode require that the decompressor be able, for examplethrough the use of a checksum, to check that the compressor anddecompressor are actually synchronized.

[0014] SO pattern

[0015] The current pattern is defined as:

[0016] second order difference (relative to the SN) of TS being null

[0017] second order difference of IP-ID being null

[0018] All remaining fields being constant.

[0019] This proves to be very well suited to audio. For a typical audiostream, the pattern should be verified for the packets generated duringa talkspurt (i.e. when actual speech is detected and encoded by theencoder). Since no or very few (comfort noise) packets are usuallygenerated during silence, this results in the first few packets of atalkspurt to be sent as FO packets and the rest of the packets sent asSO. However, this pattern is not suited to video. This can be seen onFIG. 1 and 2, which show typical cases of TS as a function of SN forrespectively audio and video. In FIG. 1, it is clear that the secondorder difference is zero over long period of times. However in FIG. 2,timestamp jumps are much more frequent (at every frame boundary) and thesecond order difference is null only over short period of times (thepackets belonging to a given frame which all have the same timestamps).

[0020] As a consequence, it might happen that in case of video, thecompression state is stuck in FO. In the reliable mode, if the linkROUND-TRIP TIME (RTT) (round trip time) is more than the frame skip (iethe time between two coded frames), the compressor can not reliably getin SO (second order) state. Even in the case of a very fast RTT or inoptimistic mode, the compression state would go back to FO at everyframe boundary.

[0021] As can be seen from FIG. 2, TS is a staircase function of SN.This staircase function could be a pattern used for SO. However toqualify as a pattern, this function has to be fully known. In otherwords, the length of a step and the jump between steps should beconstant over a large enough period of time, i.e. several times the RTT.We argue here that this can be the case, at least when B frames are notused. B frames are considered later in this document. In effect, payloadformats for video encoding are such that a given RTP packet may notcontain video data from two different frames. Two consecutive (asgenerated by the sender application) RTP packets will either have thesame RTP timestamp if they carry data from the same picture or theirtimestamp difference will reflect the time interval between theirrespective frame sampling instants. Therefore, in order to bepredictable, the number of packets per frame and the frame skip shouldbe constant. We show hereafter, that in many cases a video encoder cankeep these parameters constant.

[0022] For the sake of robustness, video applications can choose topacketize a video frame so that it contains a constant number ofmacro-bloks or in other words every video frame is sliced identically.This is much as an audio packet covers a given length of audio. The onlygood reason (at least we can think of) why the sending application wouldchoose to do otherwise is if it wanted to limit the maximum packet size.This would imply that some frames may have more packets than the usualnumber of packets per frame. However, the number of such frames willoften be limited. For example, an intra frame could be sent in a highernumber of packets. This would imply that the compression goes to FO whenthese packets are compressed.

[0023] An encoder is given a target frame rate. As long as the encodermatches its target frame rate, the timestamp jump will be constant.However, encoder implementations usually only match an average targetframe rate and the frame skip may be variable. Nevertheless, at least inthe streaming case, an encoder may use a higher buffer (higher delay)which provides greater flexibility to the rate control and maintain thetarget frame-rate throughout the connection (or at least over a longperiod of time). The invention is expected to be useful for the encodersthat have been so designed.

[0024] In addition, the RTP marker bit should be set only for the lastpacket of a frame. This can thus also be derived from the pattern.

[0025] We therefore define a pattern as:

[0026] TS is some function f of SN, where f is more general than justlinear extrapolation. For example, f can be a staircase function of SNwhich has constant length steps and constant jumps between steps.

[0027] The marker bit is also some function g of the SN. For example,the marker bit is set only for the last packet of each step

[0028] IP-ID second order difference is null (same as audio)

[0029] Using the example of video, this pattern is shown on FIGS. 3a, 3b, 3 c for a series of 40 packets where the frame rate is 10 (frames persecond) fps and the number of packets per frame is 9.

[0030] Compressor and Decompressor Logic

[0031] The only modification to the current scheme introduced by the newpattern is relative to how the compressor and decompressor transitionsbetween the FO and SO state. The compressor is the one making thedecision as to which state to operate. The decompressor follows thecompressor decisions. It operates in FO state when receiving FO packetsand it operates in SO state when receiving SO packets. The compressorlogic is shown on FIG. 4. The FO state is here conceptually divided upinto two sub-states FO_1 and FO_2. The compressor enters FO in FO_1 andmoves to FO_2 if a pattern is detected. The compressor goes from FO_2 toSO when the decompressor is synchronized, that is when the decompressorwould be able to decompress SO packets.

[0032] The issues peculiar to the new scheme are therefore:

[0033] How the decompressor decompresses packets in SO state

[0034] How the compressor acquires the pattern

[0035] How the compressor knows the decompressor is synchronized inorder to get into SO state

[0036] We examine hereafter each of these issues.

[0037] SO packets decompression

[0038] In SO state, the decompressor must know the pattern functions fand g, in order to decompress SO packets. Again using the video example,the decompressor must know n, the number of packets per frame and TS_incthe timestamp increment between two frames. In addition, it must havepreviously successfully decompressed a packet which was a first packetframe. Let call SN_0, TS_0 the sequence number and timestamp of such apacket. For any incoming SO packet, the decompressor decompresses SN asin the current scheme. If n and m are the quotient and modulo of SN-SN_0by q, i.e. SN-SN_0=q*n+m, the decompressor computes the packet TSaccording TS=TS_0+q*TS_inc. The marker bit M is set only if m=n−1. Allother fields are obtained as in the current scheme.

[0039] Pattern detection

[0040] The compressor can determine the function by observation of thestream/learning or API or some other means. Again using the videoexample, and assuming stream observation, the new pattern requiresgetting enough packets from the sender before the decision can be made.This in turn requires to buffer a copy of a certain number of pastpackets.

[0041] The pattern could be detected by searching in this buffer forthree packets whose (SN,TS,M,IP-ID) are such that the second order IP-IDdifferences are null and (SN_1,TS_1,M_1) (SN_2,TS_2,M_2) (SN_3,TS_3,M_3) are such that:

[0042] SN_2=SN_1+1

[0043] TS_3=TS_2

[0044] M_1 =1

[0045] M_2=0

[0046] M_3=1

[0047] This implies that SN_2 is a first packet frame andTS_inc=TS_2-TS_1 and The number of packets per frame is n=SN_3-SN_2

[0048] There is a particular case where the pattern can be detected bytwo packets

[0049] (SN_1,TS_1,M_1) (SN_2,TS_2,M_2) such that:

[0050] SN_2=SN_1+1

[0051] M_1=1

[0052] M_2=1

[0053] In that case, there is only one packet per frame.

[0054] Decompressor synchronization

[0055] In the current scheme, the compressor needs only to get two ACKsfrom the decompressor to make sure that the latter is synchronized. Thedecompressor derives from the last two received packets the first orderdifferences required to decompress SO packets.

[0056] However, with the new pattern, this is not enough. There areseveral ways the compressor may make sure the decompressor issynchronized. We suggest here three of them.

[0057] After detecting the pattern, the compressor can explicitly sendthe pattern functions f and g to the decompressor using in-bandsignaling. Again using the video example, the compressor sends n andTS_inc, along with an indication that the marker bit is set only for thelast packet of each step. The compressor has just then to make sure thatthe decompressor has received a packet with a marker bit set (firstframe packet). It then knows that the decompressor has all theinformation needed to decompress the packet. After receiving an FOheader carrying the pattern description, the receiver should try toacknowledge packets with the marker bit set so that the compressor canstart to send SO packets as soon as possible. Pros: decompressor logicis kept low (no need to perform pattern detection). The compressor doesnot have to know beforehand if the decompressor is not capable ofinterpreting the in-band signaling; it can be signaled by a REJECT fromthe decompressor, with cause “Not recognized”. Cons: additionaloverhead, changes to the current packet format.

[0058] Alternatively, the compressor can observe the acks received fromthe decompressor to determine if the decompressor has acquired thepattern functions f and g. The decompressor is also performing patterndetection on the decompressed packets in FO mode. When the pattern isacquired, this will be signaled in the subsequent ACKs sent to thecompressor. When the compressor gets enough ACKs to indicate that thepattern has been detected, it can start sending SO packets. Pros: theoverhead is kept at a minimum. The in-band signaling format does nothave to be standardized. Cons: the decompressor has to perform patterndetection which incurs more complexity and higher delays in the caseswhere the link loses packets used for detection; The pattern functionshave to be standardized. The compressor must also know if thedecompressor is capable of detecting the function f (the reception ofACKs alone does not ensure that the decompressor has acquired thefunction); this could be done by some capability exchange ornegotiation.

[0059] The decompressor performs pattern detection and the compressoralso performs pattern detection for the packets which have beenacknowledged by the decompressor. In other words, the compressor triesto find if the pattern can be detected using only the packets it iscertain the decompressor has received. The decompressor should thenchoose to acknowledge packets which are known to be enough to detect thepattern, for example the triplet shown above. Pros: no modificationneeded to the packet format. The same packet formats can be used for theaudio pattern and the video pattern. Cons: extra-complexity, delaybefore entering SO, reduces the freedom of the decoder to choose whetheror not to ACK a packet.

[0060] B and PB frames:

[0061] We presented the pattern as a typical pattern for video. However,in the case where B frames are used, this pattern is not followed. Wedon't consider B frames as a typical case for the following reasons:

[0062] B frames are used only by a limited number of codecs. They arenot used in MPEG 4 simple profile.

[0063] For low bit-rate video conferencing, B-frames are considered notsuitable.

[0064] This is because the P frame needs to be received before theB-frame can be decoded. For a typical 10 fps frame rate, this would meanan additional 100 ms to the end-to-end delay.

[0065] In the case where B-frames are used, there could still be atypical pattern if the encoder chooses to encode a fixed number ofB-frames per number of encoded frame, for instance every other frame isa B-frame.

[0066] Conclusion:

[0067] This scheme could be beneficial to many applications. There is nopenalty if an application does not follow the pattern. In addition, ifsuch a scheme was standardized, it could be an incentive forapplications to choose a packetization strategy that is headercompression friendly, i.e. which follows the SO pattern. In particular,designers of future video application for 3G mobile terminals could takethis into account.

What is claimed is:
 1. A method for compressing a stream arriving at acompressor comprising: acquiring a pattern at the compressor: makingsure a decompressor is synchronized with the compressor according to thepattern; and sending a compressed packet according to the pattern. 2.The method for compressing of claim 1 wherein the stream is an RTPpacket stream and the pattern comprises a TS function, a M-bit function,a quotient and a TS increment, said step of making sure comprising:sending the pattern.
 3. The method of claim 2 wherein the step of makingsure further comprises receiving an indication having a marker bit set.4. The method of claim 1 wherein the step of making sure furthercomprises: receiving a first ack; and receiving a second ack.
 5. Themethod of claim 1 wherein the step of making sure further comprisespattern detecting at least two packets.
 6. The method of claim 5 whereinthe step of pattern detecting comprises acknowledging the at least twopackets.
 7. The method of claim 6 wherein the at least two packetscomprise a first packet and a second packet and the steps prior topattern detecting comprise: receiving a first acknowledgement having atleast the first packet; and receiving a second acknowledgement having atleast the second packet.
 8. The method of claim 1 wherein the streamcomprises a first packet having a first sequence number and a first Mbit, said stream comprising a second packet having a second sequencenumber and a second M bit, the method further comprises: acquiring thefirst packet and the second packet; and detecting that the secondsequence number is one more than the first sequence number and that thefirst mbit and the second mbit are set.
 9. The method of claim 8 whereinthe stream is an RTP packet stream and the pattern comprises a TSfunction, a M-bit function, a quotient and a TS increment, said step ofmaking sure comprising: sending the pattern.
 10. The method of claim 1wherein the media stream further comprises a first packet having a firstsequence number and a first M bit, said stream comprising a secondpacket having a second sequence number, a second TS and a second M bit,a third packet said third packet having a third TS and a third M bit,the method further comprises: storing the first packet and the secondpacket and the third packet detecting that the second sequence number isone more than the first sequence number; detecting that the third TS isthe same as the second TS and detecting that the third M bit is the sameas the first M bit.
 11. The method of claim 10 wherein the stream is anRTP packet stream and the pattern comprises a TS function, a M-bitfunction, a quotient and a TS increment, said step of making surecomprising: sending the pattern.
 12. The method for compressing of claim1 comprising: acquiring the pattern at the decompressor.
 13. The methodfor compressing of claim 2 wherein the step of sending the patternfurther comprises explicitly sending the pattern from the compressor tothe decompressor.
 14. The method for compressing of claim 2 wherein thestream is an RTP packet stream and the pattern comprises a TS functionexpressed as a staircase function of the packet SN, the staircasefunction having at least one staircase step, and a M-bit function, saidstep of making sure comprising: sending the pattern.
 15. The method forcompressing of claim 14 wherein the stream is an RTP packet stream andthe pattern comprises a TS function expressed as a staircase function ofthe packet SN, the staircase function having at least one staircasestep, and a M-bit function wherein the M-bit is set for a last packet ofthe staircase step, said step of making sure comprising: sending thepattern.
 16. The method for compressing of claim 15 wherein the M-bit isset only for the last packet of the staircase step.
 17. The method ofclaim 16 wherein the step of making sure further comprises receiving anindication having a marker bit set.
 18. The method of claim 16 whereinthe step of making sure further comprises: receiving a first ack; andreceiving a second ack.
 19. The method of claim 16 wherein the step ofmaking sure further comprises pattern detecting at least two packets.20. The method of claim 19 wherein the step of pattern detectingcomprises acknowledging the at least two packets.
 21. The method ofclaim 19 wherein the at least two packets comprise a first packet and asecond packet and the steps prior to pattern detecting comprise:receiving a first acknowledgement having at least the first packet; andreceiving a second acknowledgement having at least the second packet.22. The method of claim 16 wherein the RTP packet stream comprises afirst packet having a first sequence number and a first M bit, saidstream comprising a second packet having a second sequence number and asecond M bit, the method further comprises: acquiring the first packetand the second packet; and detecting that the second sequence number isone more than the first sequence number and that the first mbit and thesecond mbit are set.
 23. The method of claim 22 wherein the patterncomprises a TS function, a M-bit function, a quotient and a TSincrement, said step of making sure comprising: sending the pattern. 24.The method for compressing of claim 16 wherein the step of sending thepattern further comprises explicitly sending the pattern from thecompressor to the decompressor.
 25. A compressor for compressing astream comprising: a means for acquiring a pattern at the compressor: ameans for making sure a decompressor is synchronized with the compressoraccording to the pattern; and a means for sending a compressed packetaccording to the pattern.
 26. The compressor for compressing of claim 25wherein the stream is an RTP packet stream and the pattern comprises aTS function, a M-bit function, a quotient and a TS increment, said meansfor making sure comprising: a means for sending the pattern.
 27. Thecompressor of claim 26 wherein the means for making sure furthercomprises a means for receiving an indication having a marker bit set.28. The compressor of claim 25 wherein the means for making sure furthercomprises: a means for receiving a first ack; and receiving a secondack.
 29. The compressor of claim 25 wherein the means for making surefurther comprises a means for pattern detecting at least two packets.30. The compressor of claim 29 wherein the means for pattern detectingcomprises a means for acknowledging the at least two packets.
 31. Thecompressor of claim 30 wherein the at least two packets comprise a firstpacket and a second packet the compressor further comprises: a means forreceiving a first acknowledgement having at least the first packet; anda means for receiving a second acknowledgement having at least thesecond packet.
 32. The compressor of claim 25 wherein the streamcomprises a first packet having a first sequence number and a first Mbit, said stream comprising a second packet having a second sequencenumber and a second M bit, the compressor further comprises: a means foracquiring the first packet and the second packet; and a means fordetecting that the second sequence number is one more than the firstsequence number and that the first mbit and the second mbit are set. 33.The compressor of claim 32 wherein the stream is an RTP packet streamand the pattern comprises a TS function, a M-bit function, a quotientand a TS increment, said means for making sure comprising: sending thepattern.
 34. The compressor of claim 25 wherein the media stream furthercomprises a first packet having a first sequence number and a first Mbit, said stream comprising a second packet having a second sequencenumber, a second TS and a second M bit, a third packet said third packethaving a third TS and a third M bit, the compressor further comprises: ameans for storing the first packet and the second packet and the thirdpacket a means for detecting that the second sequence number is one morethan the first sequence number; a means for detecting that the third TSis the same as the second TS and a means for detecting that the third Mbit is the same as the first M bit.
 35. The compressor of claim 34wherein the stream is an RTP packet stream and the pattern comprises aTS function, a M-bit function, a quotient and a TS increment, said meansfor making sure comprising: a means for sending the pattern.
 36. Thecompressor for compressing of claim 25 comprising: a means for acquiringthe pattern at the decompressor. 37.The compressor for compressing ofclaim 26 wherein the means for sending the pattern further comprises ameans for explicitly sending the pattern from the compressor to thedecompressor.
 38. The compressor for compressing of claim 25 wherein thestream is an RTP packet stream and the pattern comprises a TS functionexpressed as a staircase function of the packet SN, the staircasefunction having at least one staircase step, and a M-bit function, saida means for making sure comprising: a means for sending the pattern. 39.The compressor for compressing of claim 38 wherein the stream is an RTPpacket stream and the pattern comprises a TS function expressed as astaircase function of the packet SN, the staircase function having atleast one staircase step, and a M-bit function wherein the M-bit is setfor a last packet of the staircase step, said a means for making surecomprising: a means for sending the pattern.
 40. The compressor forcompressing of claim 39 wherein the M-bit is set only for the lastpacket of the staircase step.
 41. The compressor of claim 40 wherein themeans for making sure further comprises a means for receiving anindication having a marker bit set.
 42. The compressor of claim 40wherein the a means for making sure further comprises: a means forreceiving a first ack; and a means for receiving a second ack.
 43. Thecompressor of claim 40 wherein the means for making sure furthercomprises a means for pattern detecting at least two packets.
 44. Thecompressor of claim 43 wherein the means for pattern detecting comprisesa means for acknowledging the at least two packets.
 45. The compressorof claim 43 wherein the at least two packets comprise a first packet anda second packet further comprise: a means for receiving a firstacknowledgement having at least the first packet; and a means forreceiving a second acknowledgement having at least the second packet.46. The compressor of claim 40 wherein the RTP packet stream comprises afirst packet having a first sequence number and a first M bit, saidstream comprising a second packet having a second sequence number and asecond M bit, the compressor further comprises: a means for acquiringthe first packet and the second packet; and a means for detecting thatthe second sequence number is one more than the first sequence numberand that the first mbit and the second mbit are set.
 47. The compressorof claim 46 wherein the pattern comprises a TS function, a M-bitfunctions a quotient and a TS increment, said means for making surecomprising: a means for sending the pattern.
 48. The compressor forcompressing of claim 40 wherein the means for sending the patternfurther comprises a means for explicitly sending the pattern from thecompressor to the decompressor.